home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Atari Mega Archive 1
/
Atari Mega Archive - Volume 1.iso
/
lists
/
gem
/
l_1199
/
1053
< prev
next >
Wrap
Text File
|
1994-08-27
|
7KB
|
203 lines
Subject: Shortcuts file and other digested material
Date: Wed, 27 Jul 1994 11:41:37 +1000
From: Warwick Allison <warwick@cs.uq.oz.au>
Precedence: bulk
SHORT-CUTS file
---------------
One global file:
$APP_DEFS
or C:\SYSTEM\APP_DEFS.SYS
or C:\APP_DEFS.SYS
or "APP_DEFS.SYS" somewhere on $PATH
or .\APP_DEFS.SYS // For people who don't understand wildcards :)
(Ofir suggests these last two are bad. He's probably right)
Not just keyboard shortcuts, but general application defaults.
Application-specific and `global' setting all in the one file.
Format is "attribute_pattern: value", ie:
*.FocusProtocol: ClickToType [or PointToType or TopWindow]
*.Open: ^O
WordProcessor*.FontSize: 12pt
*MyEdit*.Open: ^E
*MyEdit*.Font: Gemini
*MyEdit*.FontSize: 10pt
An application, say `MyEdit', would search for matches to the attributes
it is interested in. For example, it would look for:
WordProcessor.MyEdit.FontSize
And that would match "*MyEdit*.FontSize", thus the setting would be "10pt".
(matches start go `bottom-up', or `override-starting-from-top')
A set of common attributes and application types needs to be decided.
>From there, we can create a APP_DEFS.SYS file that conforms to the
shortcuts standard.
Multiple formats of the `value' should be supported. For example, for
key shortcuts, a standard notation like "^O" should be used by default
app files, etc., but the user should be able to have a scancode if they
have some key on there keyboard that is not one of the one available
on all keyboards. They'll have to provide a name for it in that case -
so it can be described in a menu item. eg. shift-< and shift->, Alt-
number-pad-digit.
An application is not obliged to do what the APP_DEFS.SYS file
requests, if it doesn't provide a feature. For example, if it does not
have a Find operation, that attribute is simply ignores. Similarly, if
it suppots the std GEM TopWindow FocusProtocol, then it just uses that,
and ignores the setting in APP_DEFS.SYS.
A guide for us when thinking about the APP_DEFS.SYS file may be to look
at all those files cluttering C:\, and for each of them, ask `Could
this have been done in the APP_DEFS.SYS file?'. For example, the
NEWDESK.INF file could have used attributes like:
Desktop.NewDesk.Palette
Gemini would then have used:
Desktop.Gemini.Palette
etc.
And the APP_DEFS.SYS file would have a line like:
Desktop.*.Palette: White Black Red Green Blue ...
Or even:
*.Palette: White Black Red Green Blue ...
So that TruePaint will use that when it searches for:
Painter.TruePaint.Palette
Of course, I'm not suggesting we change all those programs, but it is
a good guide to see if our APP_DEFS.SYS file format COULD HAVE done it,
had it existed. This indicates that future programs will find it
sufficiently useful.
The APP_DEFS.SYS file might be editing in a text editor, or by a
special APP_DEFS.SYS editor (that does nice things such as allow
colours and fonts and keys to be chosen through interactive dialogs).
Other digested material...
Mark Baker:
>Why would you want keyboard events to go to a window under the top, if you've
>got to click to set the focus, why not top as well.
>If you don't have to click
>to set the focus (eg. under the mouse) the system is unusable as you can easily
>end up typing in the wrong window.
Here's the line of reasoning:
Q: When windows are non-overlapping, how do you know where
your keypresses are going?
A: The top window is highlighted differently.
Q: So you can tell the focus by the window decorations?
A: Yes.
Q: So if I changed the appearance of the window with the focus,
you would have exactly that.
This `change the appearance' could be changing the appearance of
the cursor (ala TOSWIN and XTERM), and/or it could be changing the
window colours. On AES >=4.1 and under WINX, this can be done
regardless of whether the window is on top (just wind_get the default
Active colours, and wind_set them on your window-under-focus). I hope
to be able to provide a demonstration of this in the next week.
Kevin O'Donovan:
>cut and paste from text fields
This I really miss on my machine at home, after using X11 all day at work.
Michel Forget wrote:
>Hello Warwick,
>>you can still use raster
>>copies on partially obscured windows.
>
>Could someone who understands how to do this post on the subject?
Think of how you normally scroll a window upwards 1 pixel:
1. Raster copy upwards all but the top line of pixels.
2. Redraw the bottom line of pixels.
All you do for partially obscured windows is:
For each rectangle in the window's clip list (wind_get(first/next...)):
1. Raster copy upwards all but the top line of pixels.
2. Redraw the bottom line of pixels.
ie. exactly the same, but for each clip rectangle.
(2) is, I guess, slightly tricky in that you have to work out what
to redraw, and that's slightly more complicated for the second version.
But it works like a charm.
(BTW, I wasn't criticisin MB - it *is* the fastest GEM text file viewer
available - I was just using it as an example of background windows not
being optimized)
Someone:
>Whomever:
>> Here's an idea for operating back-ground windows... put an event
>> rectangle around your window and watch for the mouse to move outside of
>> your window.
>
>This is not necessary, and it is very time-wasting. Considering, that
>when you move your mouse, you are checking the rectangles under the mouse
>for which object your mouse moves under for the top window.
Actually, `Whomever' was quite close to the mark. Using large rectangles is
the best approach. (But the remainder of Whomever's solution was incorrect,
as Someone pointed out).
In general, there are 3 solutions to hot-tracking, in order of efficiency:
1. Tracking mouse movement by large areas, only returning to the
application when it needs to re-decide the rectangle
to look at.
2. Tracking a single pixel rectangle, thus returning to the
application whenever the mouse moves.
3. Using a zero-interval timer, thus returning immediately to
the application. This is busy-waiting.
The first is a little more difficult to implement. The second and third
are both trivial. Hence the third technique can be disregarded, unless
you are already busy-waiting for other reasons (eg. continuous animation).
>Simply do this: A button "press" activates a dialog inside a background
>window. A button "click" tops the window. Press meaning hold down the
>mouse button. Click meaning tapping the mouse button.
On a fast machine, `click' should be indistinguishable from `press', unless
a real-time delay is used. Note that GEM already incorporates such a delay
for calculation of double-clicking, so if you are waiting on double-clicks,
this may be usable - I'd have to look at an actual implementation to know.
Certainly anything that depends on CPU speed is unacceptable.
--
Warwick